El dinero mueve el mundo

La transformación digital de los procesos empresariales básicos es celebrada incansablemente por el grupo de software SAP, con sede en Walldorf, como un paraíso ERP ilimitado, ágil y basado en la nube, pero un análisis crítico de las realidades contractuales revela que esta promesa es un corsé estratégico muy complejo que obliga a los clientes actuales de SAP a un bloqueo de proveedor sin precedentes.

En el centro de este cambio tectónico se encuentra el cambio de paradigma del modelo clásico on-prem basado en la propiedad a un modelo de suscripción en la nube, flanqueado por una opaca lista de precios y condiciones (PKL), nuevas restricciones de las API y la rigurosa monetización de los flujos de datos.

Para los clientes existentes de SAP, el cambio a S/4 Hana ya no significa una actualización técnica de la versión, sino un reajuste fundamental de su arquitectura de TI comercial, donde el riesgo de explosiones de costes, exceso de licencias y la pérdida total de soberanía digital es un compañero constante. Cualquiera que no deconstruya los mecanismos de SAP Cloud Subscription, la Business Technology Platform (SAP BTP), la Business Data Cloud (SAP BDC) y las nuevas métricas de licencias hasta el más mínimo detalle será inevitablemente víctima de una máquina de monetización magistralmente orquestada.

La transición histórica de SAP al mundo de la nube, impulsada principalmente por los paquetes contractuales integrales Rise and Grow, marca un complejo cambio del gasto de capital (capex) al gasto operativo continuo (opex) para los usuarios de ERP. Mientras que las licencias on-prem se adquirían como propiedad perpetua y garantizaban el derecho legal permanente a utilizar el sistema aunque se rescindieran los contratos de mantenimiento, la suscripción a la nube degrada al cliente a inquilino indefenso.

SAP está convirtiendo las licencias on-prem existentes en suscripciones a la nube mediante la conversión de contratos, lo que conlleva la destrucción irrecuperable de las antiguas y valiosas licencias de compra. El instrumento central de esta transformación es la métrica Full Use Equivalent (FUE), un conjunto de reglas muy complejo que presiona la anterior asignación detallada de usuarios basada en el uso del mundo ECC hacia tipos de uso estandarizados en la nube.

Una FUE sirve como unidad de facturación, que se asigna a tipos de usuario como Acceso de desarrollador, Uso avanzado, Uso básico o Uso de autoservicio utilizando diferentes factores de ponderación. El reto crítico para los clientes actuales de SAP radica en la base de valoración: en el nuevo mundo de S/4 Cloud, SAP ya no concede licencias principalmente en función del uso real del software, sino rigurosamente en función de las autorizaciones asignadas en el sistema.

Medición basada en autorizaciones

Dado que las autorizaciones se asignaban a menudo de forma extremadamente generosa en los entornos SAP R/3, R/3 Enterprise y ERP/ECC 6.0 (SAP Business Suite) ya crecidos, esta medición basada en autorizaciones conduce a un exceso masivo de licencias en caso de una migración no preparada.

Expertos independientes en licencias advierten de que la nueva métrica de la nube puede disparar los costes de las licencias entre un 50 y un 150 por ciento, ya que incluso los usuarios ocasionales tienen que pagar de repente las caras licencias Profesional o Avanzada en cuanto se les asignan funciones de gran alcance en el sistema.

SAP intenta ayudar a los clientes con la clasificación mediante el llamado S/4 Trusted Authorisation Review (Star Service), pero esta herramienta analiza sin rodeos los objetos de autorización y asigna automáticamente el tipo de licencia más caro a los casos poco claros, lo que se considera una trampa de costes muy peligrosa para los usuarios desprevenidos.

La base contractual de estas construcciones en la nube es la lista de precios y condiciones de SAP, que se ha convertido en un auténtico laberinto legal en la era de la nube. La PKL ya no consiste en una simple lista de precios en Excel y un documento maestro, sino que se fragmenta en una red inmanejable de suplementos en la nube, guías de descripción de servicios, condiciones generales en la nube y acuerdos de nivel de servicio (SLA), todos ellos componentes inseparables del denominado formulario de pedido.

Suplementos Toxic Cloud

Los suplementos de la nube regulan en detalle las restricciones de uso, las métricas y los detalles de aprovisionamiento de cada servicio en la nube. El elemento tóxico es que SAP cambia y adapta estos documentos y métricas trimestralmente, lo que imposibilita la elaboración de presupuestos fiables y a largo plazo para el director financiero. Para los clientes actuales de SAP, esto significa que se ven obligados a archivar los suplementos diarios de forma legalmente conforme cada vez que se celebra o renueva un contrato, ya que SAP se reserva el derecho a realizar ajustes de precios unilaterales cuando se amplía el plazo o a tarificar de repente funciones que antes se incluían por separado.

Los riesgos comerciales son aún más drásticos cuando se trata de la Plataforma Tecnológica Empresarial, que SAP promueve como la columna vertebral técnica y la capa de innovación esencial de la estrategia de núcleo limpio. En el futuro, todas las extensiones personalizadas (extensibilidad side-by-side) e integraciones tendrán lugar en la BTP para mantener el núcleo digital de S/4 Hana limpio y actualizable.

BTPEA y Cloud Bill Shock

Los servicios de BTP se licencian principalmente a través de modelos de consumo basados en el consumo, a saber, el Cloud Platform Enterprise Agreement (CPEA) o el más reciente BTP Enterprise Agreement (BTPEA), en virtud de los cuales el cliente adquiere créditos de nube por adelantado. El escollo comercial de estos modelos reside en la inminente caducidad de los créditos adquiridos: Los créditos de nube no utilizados caducan sin excepción al final de cada año de contrato, lo que crea una presión extrema para consumir realmente los servicios con el fin de evitar la financiación del llamado shelfware.

Al mismo tiempo, la temida factura de la nube acecha en caso de uso intensivo. En cuanto se agota la cuota de créditos de nube adquirida previamente, SAP facturará sin piedad cualquier uso excesivo posterior al precio de lista sin descuento. Como alternativa, SAP ofrece un modelo de pago por uso, que no requiere una cantidad mínima de compra, pero en el que las tarifas de servicio no son descontables y, por lo tanto, es el más caro de todos los modelos operativos cuando se utiliza a escala.

La gestión y supervisión de estos consumos de BTP a través del portal SAP for Me o del BTP Cockpit es criticada por asociaciones de usuarios como DSAG como muy inadecuada y poco transparente, ya que a menudo faltan evaluaciones de costes granulares a nivel de procesos empresariales individuales. SAP Integration Suite, el sucesor basado en la nube del clásico middleware SAP PI/PO de la pila NetWeaver, presenta un panorama igualmente restrictivo. La concesión de licencias de esta herramienta de integración esencial, indispensable para conectar sistemas SAP y no SAP, se basa a menudo en métricas como inquilinos y paquetes de 10.000 mensajes cada uno.

El reto empresarial para los clientes actuales de SAP reside en la previsibilidad de los volúmenes de mensajes. En los modernos entornos ERP y escenarios IoT basados en eventos, el número de mensajes del sistema que deben procesarse a menudo explota de forma incontrolable. Dado que Integration Suite se aprovisiona de forma centralizada a través del BTP, es prácticamente imposible asignar servicios internamente a departamentos específicos, mientras que los picos de carga repentinos agotan rápidamente el saldo de crédito de la nube y provocan costes adicionales incalculables.

Sin embargo, el pináculo de la estrategia de monetización de SAP se revela en la nueva Business Data Cloud (SAP BDC) y la SAP Datasphere. La BDC es elogiada por el marketing de SAP como una base de datos abierta y armonizada (data fabric) que romperá los silos de datos históricos de SAP y los federará con servicios de hiperescalado como Databricks o Snowflake. Sin embargo, si se lee la letra pequeña de los contratos y las Guías de Descripción de Servicios, la BDC resulta ser un sistema de tornillos de mariposa restrictivos que DSAG califica acertadamente de „Complejidad de Datos Empresariales“. SAP impone límites muy estrictos a la utilización de los datos. Cada vez que se superan los límites mínimos, SAP se reserva el derecho de penalizar con cargos adicionales y severos. Estas duras barreras técnicas y comerciales frustran por completo la promesa de una cultura de datos abiertos y obligan a las empresas a estrangular sus análisis de datos precisamente de acuerdo con las costosas especificaciones de volumen.

Política API de SAP

Esta táctica aislacionista se ve agravada por la muy controvertida nueva política de API publicada por SAP en abril de 2026. Con el pretexto de la seguridad y la estabilidad del sistema, SAP regula ahora con precisión las condiciones en las que los clientes existentes pueden transferir sus propios datos a sistemas de terceros.

La directriz sobre API prohíbe explícitamente el uso de las API de SAP para fines que no estén expresamente documentados y prohíbe las extracciones sistemáticas masivas de datos a almacenes o centros de datos externos.
Lakes, a menos que SAP haya permitido explícitamente este caso de uso específico en la documentación del producto.

Para los actuales clientes de SAP, esto supone un golpe fatal a su propia soberanía digital. Quien en el futuro quiera extraer de forma eficiente sus datos históricos de S/4 para analizarlos con herramientas de IA de terceros proveedores o en plataformas como Microsoft Fabric, se verá obligado de facto a recurrir a costosas soluciones internas como SAP Datasphere y SAP BDC debido al bloqueo de interfaces de alto rendimiento (como ODP).

La prohibición de los agentes de IA autónomos y generativos de terceros proveedores es especialmente controvertida: los sistemas de IA ya no pueden acceder de forma libre e independiente a los datos de SAP a través de API. SAP está erigiendo aquí una barrera aduanera digital, en la que cualquier acceso externo que afecte a la soberanía de datos de Walldorf será regulado en el futuro y, casi con toda seguridad, monetizado con el fin de garantizar una ventaja competitiva artificial para sus propios asistentes de IA, como Joule, que a menudo van a la zaga técnicamente.

Las restricciones de API se fusionan a la perfección con uno de los problemas de licencia más peligrosos de la historia de SAP: el uso indirecto y el modelo de precios Digital Access. En la era de la Industria 4.0, la automatización de procesos robóticos (RPA) y las cadenas de suministro en red, innumerables sistemas de terceros acceden automáticamente al sistema ERP. Con Digital Access, SAP ha creado un modelo de licencia basado en resultados que ya no tiene en cuenta al usuario humano, sino el gran número de documentos creados inicialmente en fuentes ajenas a SAP e importados al núcleo de SAP. Los precios de catálogo para este volumen de documentos son astronómicamente altos, por lo que SAP tiene que atraer a los clientes al nuevo modelo con programas de descuento (Digital Access Adoption Program, DAAP) de hasta el 90 por ciento.

Pero estos descuentos son una ilusión contractual: una vez que una empresa ha optado por el acceso digital, no hay forma de volver al antiguo mundo basado en el usuario, potencialmente más rentable. Las herramientas de medición inadecuadas, como la herramienta SAP Passport, suelen hacer recaer por completo en el cliente la carga de la prueba del recuento correcto de los documentos, como la distinción entre los documentos nuevos que requieren licencia y los que se leen sin licencia (lectura estática indirecta). Cualquier agente externo de IA o sensor IoT que cree de forma autónoma pedidos en S/4 Hana en el futuro hará que las lecturas del contador de Digital Access se disparen y den lugar a cargos adicionales sin una gobernanza estricta.

Estrategia de salida de la nube

Sin embargo, el peligro último del modelo de suscripción a la nube de SAP se revela en su final: simplemente no existe una estrategia de salida de la nube nativa y contractualmente garantizada por parte de SAP. Los contratos "todo en la nube" suscritos con SAP actúan como una función de trampilla matemática, una calle estratégica de sentido único. Como el cliente ha tenido que renunciar irrevocablemente a sus licencias perpetuas on-prem durante la conversión del contrato, se queda con las manos vacías al final de la vigencia del contrato en la nube. Si una empresa usuaria ya no puede o no quiere pagar las caras cuotas de suscripción, el derecho a acceder al software expira inmediatamente.

Esta asimetría coloca a SAP en una posición de monopolio absoluto con cada próxima renovación de contrato, lo que permite al grupo dictar despiadadamente subidas unilaterales de precios y métricas menos favorables sin que el cliente tenga una oportunidad realista de cambiar.

Los esfuerzos legales de la Unión Europea a través de la Ley de Datos de la UE, que pretende acabar con los efectos de bloqueo de la nube y hacer cumplir la portabilidad de datos, también son en gran medida ineficaces en la práctica de ERP, ya que la ley regula la salida de datos técnicos, pero no resuelve el problema de la falta de licencias de aplicación para el posterior procesamiento de datos.

Transparencia y optimización

En vista de este terreno comercial minado, E3 Magazine, de acuerdo con expertos independientes en licencias y DSAG, ha formulado a menudo recomendaciones drásticas pero esenciales para todo cliente SAP existente: La máxima prioridad es la transparencia absoluta y la optimización del propio panorama de licencias antes incluso de firmar un contrato Rise-with-SAP o en la nube. Bajo ninguna circunstancia debe embarcarse en el viaje a la nube con un legado histórico y un "shelfware" sin utilizar.

Los clientes actuales de SAP deben recuperar el control de sus estructuras de usuarios y autorizaciones. Dado que las futuras métricas de S/4 se basarán en las autorizaciones asignadas y ya no en el puro uso, es imprescindible rediseñar los roles de SAP antes de aplicar el propio Star Service de SAP.

Se recomienda encarecidamente utilizar herramientas independientes de gestión de activos de software (SAM) de proveedores especializados como USU, Snow, Flexera o Dynamic License Control, que simulan el uso real y muestran qué objetos de autorización caros en los roles pueden eliminarse para evitar una clasificación fatal en las costosas licencias profesionales. Si se hace limpieza por adelantado, se puede reducir masivamente el requisito final de FUE para la nube.

El equipo editorial de E3 advierte contra la conversión prematura de sus propias licencias de compra perpetua on-prem al modelo de suscripción en la nube (conversión de contrato). Siempre que siga siendo contractualmente posible y sensato, debe insistirse en una conversión del producto que garantice la conservación de la cartera de licencias y los antiguos derechos de uso especiales.

Para las empresas que aspiran a operar en la nube pero quieren mantener su soberanía digital, se recomienda el modelo BYOL (bring-your-own-licence) en la infraestructura de un hiperescalador neutral (IaaS) o Green Lake de Hewlett Packard Enterprise. En este caso, el cliente SAP existente sigue siendo el propietario legal de las licencias de software y puede cambiar de proveedor de alojamiento o transferir las licencias a su propio centro de datos (nube privada local) si no está satisfecho.

Los escollos del BTP y la utilización indirecta deben negociarse meticulosamente. Al utilizar el BTP Enterprise Agreement (BTPEA), las empresas nunca deben empezar con paquetes de créditos en la nube demasiado grandes, ya que los volúmenes no utilizados caducan inevitablemente al final del año. En su lugar, debería optarse por empezar con volúmenes pequeños o utilizar modelos de suscripción seguros para servicios claramente definidos y requeridos de forma permanente (como la Suite de Integración).

En cuanto al acceso digital, las empresas deben analizar con precisión la arquitectura de sus sistemas y todas las interfaces con sistemas ajenos a SAP antes de una auditoría. No toda transferencia de datos desencadena automáticamente un recuento de documentos; funciones como la lectura estática indirecta deben seguir siendo contractualmente estancas y definirse como gratuitas.

Precisión forense

Al leer los contratos de SAP, hay que aplicar una precisión casi forense. Un contrato de nube de SAP no se formaliza en el formulario de pedido. Los clientes actuales de SAP deben descargar, leer y archivar físicamente los Suplementos de Nube y las Guías de Descripción de Servicios más recientes del Centro de Confianza de SAP, ya que son precisamente estos documentos los que definen las métricas duras, las restricciones (como el límite de 2000 llamadas a la API OData en la BDC) y los acuerdos de nivel de soporte. Dado que SAP modifica periódicamente estos enlaces y documentos, no hay posibilidad de aportar pruebas en caso de litigio sobre licencias sin un archivo sólido.

Los responsables de la toma de decisiones críticas en materia de TI deben comprender que el actual modelo de licencias de SAP para la nube y ERP no sirve principalmente para liberar al cliente, sino que representa una red comercial magistralmente construida para maximizar y estabilizar los ingresos de SAP.

Cualquiera que confíe en las presentaciones de Rise-with-SAP sin una estrategia informática sólida, sin asesoramiento jurídico externo y sin herramientas de licencia independientes caerá inevitablemente en una trampa de costes que elevará ruinosamente el coste total de propiedad durante años y dejará a la empresa permanentemente dependiente del gigante del software.

Hoy en día, la soberanía digital de los actuales clientes de SAP ya no puede asegurarse confiando ciegamente en la hoja de ruta de SAP, sino que requiere una responsabilidad personal radical, un profundo conocimiento técnico y contractual y la voluntad de enfrentarse al líder del mercado mundial de ERP a la altura de los ojos y con el máximo rigor en cada negociación de licencia.